\chapter{Plugin}

	\section{Introducción}
Uno de los requerimientos fundamentales de este sistema es la posibilidad de extensión y modificación de funcionalidad por parte de sus usuarios. La idea general radica en que el usuario de este software pueda agregar información o cálculos específicos, como ser en las funciones de scoring,la generación del nodo, función de poda, etc. Para esto proveemos un mecanismo de integración de plugins implementados con librerías dinámicas del sistema, dando libertad para explorar teorías o cálculos que se requieran.

    \section{Plugin}
Este ha sido uno de los requerimientos principales desde el primer planteo del sistema, ya que representa uno de los componentes principales que permiten extender la funcionalidad sin modificar el framework (OCP). Fue esa la razón por la cual se hizo distinción entre los tipos de usuarios mencionados en el capítulo 1. Apuntamos a que el sistema pueda ser altamente parametrizable a través de este mecanismo de plugins.

	\section{Nodo de Terapia}
	Anteriormente nos habíamos referido a las terapias como ramas en un árbol en donde cada nodo representa la aplicación de una nueva combinación de antirretrovirales y la secuencia mutante del virus, causada por esta. Cada elemento del árbol es denominado como Nodo de Terapia ($TheapyNode$) y que consta de lo siguiente:
	\begin{enumerate}
	\item Un identificador único.
	\item Una referencia a su nodo padre (si es que posee).
	\item Una secuencia nucleótidica.
	\item El conjunto de antirretrovirales que produjeron la secuencia.
	\item Algoritmo de combinación.
	\item Información extra que se quiera agregar a cada paso.
	\end{enumerate}
	

	\section{Alcance del Plugin}
La integración del plugin al sistema permite modificar funcionalidades u obtener información especifica, siendo este capaz de poder realizar las siguientes extensiones o cambios:
	\begin{itemize}
	\item Elegir la política de generación entre las disponibles o proponer una propia: el capítulo 7 se presentaron cuales son las políticas proporcionadas por el sistema a través del SDK. El usuario que implementa el plugin también puede usar su propia política de generación implementando la interfaz $GenerationPolicy$.
	
	\item Definir una función de scoring especifica, que asigne un puntaje a una terapia: esta función tiene una gran responsabilidad a la hora de construir las terapias, ya que un scoring adecuado proporcionaría mejores resultados. Esta función debe satisfacer la interfaz $Score\ scoring()$ y puede ser tan compleja como se desee, además debe ser especificada en el plugin. 
	
	\item Cambiar la implementación interna de ciertos tipos de datos como $Info$, $TherapyNode$ y $Antiviral$. Permitiendo incorporar información adicional para cálculo y fundamentación de la terapia ante el usuario.
	
	\item Definir una función de poda en el espacio de búsqueda de terapias. Esta se encarga de eliminar del árbol de terapias todas aquellas, que por diversos motivos sean inviables desde el punto de vista de los criterios definidos en el plugin. En el sistema implementa la interfaz $TherapyStatus\ continue\_therapy()$ y establece el estado de una terapia parcial ($TherapyStatus$).
	
	\item Seleccionar cuales serán los antirretrovirales a utilizar. Esta opción permite seleccionar, de la Base de Datos, un subconjunto de antirretrovirales antes de hacer el cálculo. Descartando aquellos que por ejemplo no están disponibles en la zona o se consideran innecesarios.
	
	\item Elegir la primitiva combinatoria (presentado en el capítulo 8) a aplicar en cada paso de la terapia. Estas primitivas se establecen en cada $TherapyNode$ de la terapia al momento de generar el nodo.
	
	\item Capacidad de interactuar con el usuario en tiempo de ejecución: el plugin puede solicitar al usuario una cantidad variable de parámetros para realizar sus cálculos internos. Por ejemplo, recuento de CD4, edad del paciente, etc. Es decir, el sistema proporciona los mecanismos para que las funcionalidades del plugin se comuniquen con el usuario en tiempo de ejecución. 

	\item Definir los valores de la matriz de distancia de nucleótidos: la distancia entre un nucleótido y su mutante está dado por una matriz que define cada distancia. El plugin es capaz de establecer cual es su valor.	
	\end{itemize}
	
Por otro lado el plugin no permitirá:
	\begin{itemize}	
	\item Modificar registros de la base de datos: dado que la base de datos es reutilizada para otros cálculos, no es conveniente permitir que se eliminen ó alteren registros.
	\item Establecer el orden del Ranking: de forma predeterminada el ranking esta ordenado de mayor puntaje a menor puntaje en base a la función de scoring, es decir, de la mejor en adelante. No se posibilita que el plugin decida otro orden basado en algún otro criterio.
	\item Elegir la forma en que un antirretroviral aplica: el sistema trabaja con definición de aplicación de los antirretrovirales de acuerdo de sus posiciones de resistencia, pero podría ocurrir que trabaje con probabilidades u otros enfoques. Por el momento el sistema no soporta otra forma para considerar antirretrovirales. 
	\item Cambiar la forma en que funciona el Administrador de Plugins: El $Plugin Administrator$ es el encargado de integrar el $Plugin$ al sistema, un plugin no puede modificar la forma en que se integrara al sistema ya que podría ser causal de un funcionamiento erróneo.
	\end{itemize}
	
	\section{Administrador de Plugin}
La entidad a través de la cual el sistema se comunica con un plugin es el $Plugin Administrator$, este es parte del framework y establece en que partes del sistema tendrá injerencia el plugin. provee las siguientes funcionalidades:

	\begin{itemize}
	\item Cargar un plugin: introducir al sistema todas las funcionalidades provistas por el plugin.
	\item Descargar un plugin: remover del sistema los elementos del plugin, permitiendo introducir uno diferente.
	\item Chequear consistencia: del plugin con el sistema y del plugin con la base de datos.
	\item Obtener la lista de parámetros: lista de argumentos necesarios para que el plugin haga los cálculos y que debe establecer el usuario.
	\end{itemize}

Es decir, el plugin por sí solo no provee una interacción con el framework, si no que implementa las funcionalidades. El $Plugin Administrator$ maneja esas implementaciones y las introduce al sistema, haciendo un chequeo de consistencia.

\section{SDK Libpluginaso}
Las herramientas básicas para construir un plugin están provistas por la librería $libplguinaso$. El SDK tiene como objetivo simplificar la creación de plugins a los usuarios con conocimientos básicos de computación.\\
 
 El usuario que desarrolle plugins debe definir cada una de las primitivas en la interfaz $Plugin$ y $TherapyNode$, ó usar como base de desarrollo el plugin Base explicado más adelante. 
 
	\subsection{Implementación}
	Se optó por utilizar librerías dinámicas de C++ para su implementación, ya que si bien se había propuesto confeccionar el plugin en lenguaje Pyhton, decidimos que para el alcance de este trabajo es más viable poder implementar los plugins en el mismo lenguaje del framework. Sin embargo sugerimos que en próximas versiones del sistema se incluya la posibilidad de manejar plugins con este otro lenguaje ya que es común su uso por parte de especialistas en el área de la biología.

	\subsection{Compilación de un plugin}
	Los recursos necesario para la construcción del plugin se encuentran en el directorio $libplugin$. Una vez confeccionado el plugin con las funcionalidades deseadas se compila con el $Makefile$ que se encuentra en ese mismo directorio. Esto crea un archivo con extensión $.so$ que será utilizado en el framework.

	\subsection{Base Plugin}
Para este trabajo incluimos otro plugin con funcionalidades por default, que implementa parte de las interfaces necesarias a un nivel sumamente básico. Tiene como objetivo proveer una base a partir de la cual generar plugins más complejos.
\begin{itemize}
\item Nombre: \begin{tt}Default Plugin\end{tt}
\item Función de Scoring: sin implementación.
\item Función de poda: $Continue$. Siempre continuar la terapia. 
\item Política de generación: \begin{tt} Width \end{tt}
\item Política de Combinatoria: \begin{tt} Empty\end{tt}. Sin combinatoria.
\end{itemize}


	\section{Thesis Plugin}
	Se provee un plugin en este trabajo, con muchos de los lineamientos más generales del tratamiento contra el VIH. $ThesisPlugin$ fue pensado a modo de ejemplo, su función es mostrar como se usan muchas de las herramientas del SDK. Vale aclarar que tiene cierta complejidad y cuenta con las siguientes funcionalidades:
	
	\begin{itemize}
	\item Nombre: \begin{tt}Thesis Plugin\end{tt}
	
	\item Función de Scoring:
	Esta función retorna la suma de las distancias mínimas entre mutantes.

\begin{minipage}{\linewidth}
\begin{lstlisting}[basicstyle=\tt, frame=trBL, tabsize=4,fontadjust=true]	
score scoring(node)
{
	if(parent(node) != NULL)
    	partialTherapyScore = scoring(parent(node)) + value(node);
    else
    	partialTherapyScore = value(node);
}
\end{lstlisting}
\end{minipage}
Se computa al scoring sumando los valores que posee el nodo.
	
	\item Función de Poda:
 	Esta función retorna siempre $Continue$, por lo cual ninguna terapia se descarta.
 	
	\item Política de generación:
	Se decidió usar una política exhaustiva como \begin{tt}Depth\end{tt}, la cual permite activar ciertas optimizaciones en el manejo de memoria.
	
	\item Política de Combinatoria:
	Se decidió inicialmente combinar con tres antirretrovirales, en particular comenzar con dos de tipo $NNRTI$ y uno $PI$ o con dos de tipo $NRTI$ y uno $PI$ . Continuar así hasta que se llegue a un fallo virológico y entonces descartar el antirretroviral para el cual ocurrió el fallo y seguir con combinaciones de tamaño dos, repetir este proceso en cada fallo virológico, hasta que no queden más.
		
	\item Matriz de Distancia:
	Se necesita tomar una matriz con distancia entre nucleótidos igual a 1.
	
\begin{minipage}{\linewidth}
\begin{lstlisting}[basicstyle=\tt, frame=trBL, tabsize=4,fontadjust=true]
set_default_matrix(DistanceMatrix Matrix)
{
	for all (columns in Matrix) do
	{
		for all (rows in Matrix) do
		{
			if(row==column) then 
				Matrix[row][column] = 0
			else 
				Matrix[row][column] = 1
		}
	}	
}		
\end{lstlisting}
\end{minipage}
Es Decir, la matriz quedaría definida como sigue:
	
\begin{tabular}{|c|c|c|c|c|}
\hline  & A & C & G & T \\ 
\hline A & 0 & 1 & 1 & 1 \\ 
\hline C & 1 & 0 & 1 & 1 \\ 
\hline G & 1 & 1 & 0 & 1 \\ 
\hline T & 1 & 1 & 1 & 0 \\ 
\hline 
\end{tabular}	 
	
	\end{itemize}
	

	
	

	
	
	